
REMARKS 

Favorable reconsideration of this application as presently amended and in light of the 
following discussion is respectfully requested. 

Claims 10, 12-19, 36, 38-45 and 52-61 are pending in the present application; Claims 
1 1 and 37 having been cancelled. Claims 10 and 36 having been amended, and Claims 52-61 
having been added by way of the present amendment. 

Before addressing the merits of the outstanding Office Action, it is noted that the 
Form PTO 1449 which was included with the Official Action of December 8, 1997, did not 
include an indication that the WIPO document number 91/1 1871 was considered by the 
Examiner, The next Official Action is respectfully requested to provide a copy of this form 
PTO 1449 which indicates that the WIPO document has been considered. 

Some of the changes made to the specification were made for the same reasons these 
changes were made in the parent application. Additionally, the drawing change made herein 
was made for the same reason it was made in the parent application. The other changes made 
to the specification include well-known Internet e-mail addressing and format techniques and 
are supported by the various documents cited in the specification. 

In the outstanding Office Action, Claims 10-19 and 36-45 stand rejected under 35 
U.S.C. § 103 as being xmpatentable over Kraslavsky et al in view of Johnston et al . This 
rejection is respectfully traversed. 

Independent Claim 10 has been amended to include the limitations of Claim 11, and 
Claim 1 1 has been cancelled. Similarly, independent Claim 36 has been amended to include 
the limitations of Claim 37 and Claim 37 has been cancelled. Dependent Claims 1 1 and 37 



-5- 




whose subject matter was incorporated into the corresponding independent claims pertains to 
the use of an Internet electronic mail message. 

Intemet electronic mail messages, according to this specification, are connectionless 
modes of communication. The outstanding Office Action at the third and fourth lines of page 
3 acknowledge that Kraslavsky et al do not explicitly teach transmitting the information by a 
connectionless mode. However, in numbered paragraph 5 of page 3 of the outstanding Office 
Action, it is stated that Kraslavsky et al teach the transmitting of the information as an 
Intemet electronic mail message. However, this statement that Kraslavsky et al teach the 
transmitting of an Intemet electronic mail message is clearly erroneous as lines 3 and 4 of 
page 3 of the outstanding Office Action acknowledge that Kraslavsky et al do not teach the 
transmitting of information by a connectionless mode. If Kraslavsky et al actually did teach 
the transmission of an Intemet electronic mail message as asserted at numbered paragraph 5, 
then Kraslavsky et al would teach the concept of a connectionless mode but as acknowledged 
by the Examiner, Kraslavsky et al do not teach the transmission of a connectionless mode. 
Therefore, Kraslavsky et al clearly do not teach the transmission of an Intemet electronic mail 
message. 

What Kraslavsky et al teach at column 11, lines 13-17, is the sharing of resources 
from one LAN to another which is the sharing of network resources. However, the mere fact 
that network resources are shared "intemet" does not mean that electronic mail messages are 
sent. Thus, the rejection of dependent Claims 1 1 and 37 whose subject matter has been 
respectively incorporated into independent Claims 10 and 36 is clearly erroneous and 
therefor, independent Claims 10 and 36 and each of the claims depending therefrom should 
be allowed. 
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The added dependent claims recite further features of the electronic mail message and 
the use of the firewall. For example, dependent Claims 52, 53, 55, 56, 57, 58, 60 and 61 
pertain to the format of the electronic mail message. A manner of transmitting Internet 
electronic mail messages includes an identifier followed by the "@" symbol followed by a 
domain name. Further, Internet electronic mail messages typically include the description of 
an encoding type of the electronic mail message. These features of Internet electronic mail 
are utilized by the BSD Unix mail system which may be used to implement the invention, as 
described on page 1 8 of the specification. Further, the specification has been amended to 
include these features of the BSD Unix mail system. These features are included in 
conventional email systems and are described, for example, at pp. 441-445 of "TCP/IP 
Illustrated, Volume 1 " by W. Richard Stevens, 1 994, which are included herewith as an 
Appendix. The addition of these features to the specification and claims does not constitute 
new matter as they are utilized by the BSD Unix mail system and the specification describes 
that the invention can be implemented by the BSD Unix mail system. It is to be noted that 
the claims, while reciting features of the Unix mail system, are not limited to the use of a 
Unix mail system but are limited to general implementations of an Internet electronic mail 
message system. 

As the specific features pertaining to an Internet electronic mail message which are 
recited in the added claims are neither disclosed nor suggested by the prior art of record, the 
added dependent claims pertaining to this feature are patentable. 

Further, added dependent Claims 54 and 59 and the claims depending therefrom recite 
the use of a firewall through which the Intemet electronic mail message is transmitted. The 
use of a firewall is useful as it may be used to reject direct connections with the destination 
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but may be configured to allow electronic mail messages which are typically harmless to pass 
therethrough. Thus, the present invention achieves an advantage by utilizing the combination 
of a firewall and electronic mail message in order to transmit the information, as set forth in 
Claims 54 and 59 and the claims depending therefi*om. 

Accordingly, each of the added dependent claims is patentable over the prior art of 



Consequently, in light of the above discussion and in view of the present amendment, 
the present application is in condition for formal allowance and an early and favorable action 
to that effect is requested. 
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Appendix 
Serial No* 08/738,659 




SMTP: Simple Mail 
Transfer Protocol 



11 Introduction 

^^''i^^o^'.ri" ^^""^^ undoubtedly one of the most popular applications fCaceres 

sZm^Uo^d fh^JTh ^ ' ''^'^ '^r' ^ carry more dataO [Pax- 

bon 1993J found that the average mail message contains aroiind 1500 bytes of data but 

Figure 28.1 shows ax\ outline of e-mail exchange using TCP /IP. 
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FiffureZS.l OutUne of Internet electronic mail. 

^^'^ag'lnt f^T\ "^^"^ ^^^^^ ^ ^ multitude to choose from. Popular 

gents for Unix include MH, Berkeley Mail, Elm, and Mush. ^ 
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ThJ^lZ^ ^ li^^ "^^^ performed by a message transfer agent (UTA^ 

most common MTA for Unix systems is Sendmail. Users nonnaUy don't dealw if 
the MTA. It 13 the x^ponsibility of fhe system administrator to set up CiocJ 1^? 
Users otten have a choice, however, for their user agent 

TrP^t? ^P*';?''r^f' '^^ ^'''^^^g^ °^ electronic mail between the two MTAs u.in 
TCP. We do not look at the operation or design of user agents 

„i..I^^-f? '^u**^ ^V^^ the SMTP protocol. Tliis is how two MTAs com™ 
mcate with each other across a single TCP conaaection. RFC 822 [Crocker Till sn^??"" 



28.2 SMTP Protocol 

'"^^ NVT ASCII. Commands are sent hv 

the cUent to the server, and the server responds with numeric reply codeHnd otn ! \ 
hjuman-readable strings. This is similarno what we saw"witf the^tvS 

thnn^H^/"^ *m """^ "^^"^^^-^ *at the client can send to the server- less 

^an a dozen. (By comparison, FTP has more than 40 commands.) Rather ttiSTe^criS^ 
mg^each one, we'U start with a simple example to show what happens when wrs^^d 

Simple Example 

We'll send a simple one-line message and watch the SMTP connection We invoke onr 

J^hen tltV?^ MTA displays what is sent and received acro^ss the SMTP coimection 
^Jn. tn^^ IS spcohed. Lmes begim^g with >» are comnwds sent by the SmS 



3uh % mail -v rstaven9@n0A0.adu 

To: rstevenaQncao. edu 
Subject; teating 

1, 2, 3. 



Sending lettQr 



rscavenaGnoao . edu . 



invokti our user agent 

this is output by iu>er agent 

we're then fmmpted for a subject 

user agent adds one blimk lin^ betzueen headers and body 

this IS what xve type as tJie body of the mestiage 

iu€ type a period on n line by itself to say lue're done 



Connecting to mailhost via ethar. 
Trying 140.252.1.54... connected. 
220 noao.ddu Sendmail 4 . 1/SAG-Moao . G89 
»> HELO 3un.tuc.noao.edu. 
250 noao.edu Hello aun . tucnoao . adu . . 



verbose output fivm user agent 
foUotuing is output by MTA (Sendnuiil) 

veady tit Moft, 19 Jul 93 12:47:34 



MST 



»> MAIL irroin:<ratevens0sun.tuc.naao.edu> 
250 <rstevensesun.tuc.noao.edu>. . . Sender ok 



pleased to meet you 



|Wb0£:TTB866T "6 'dt 




»> aCPT 'eo:<r3teven3(?noao.eda> 

250 <r3cev6ns9noao.edu>. . . Recipient cK 



>^> DATA 

3 54 Enter mail/ end with 
>» . 

250 Mail accepted 

»> QUIT . . , 

221 noao.edu delivering mail 

rscevensSnoao.edu... Sent 
sent . 



on 



a line by itself 




this is output by user n^ent 



Only Sve SNTTF co^nands »e used to send *e HE,0. MAIL, RCFT, DATA, and 
. , , Mo«r ^<rpnt We're then prompted for a subject, and 
We type mail to mvoke om user , period on a line by itself 

after typing that, we type the body '^^i^Jes the nSl to tlAe MTA for delivery, 
completes the message and the u.er ag^i^P^^^^f men this returns, the client waits 
The cUent does the active open 'f'Jf f This server's response must 

for a greeting message (reply code 220) ^'^f J^^J^/: ^^^^ . edu in this exam- 

pie. (NonnaUy the text tnatio io^^^^^^^^^^^ ^^_^ 

multiple recipients. . ^ 1^ ^l^g DATA coniniand. 

XKe^:rrr'4-"pS-yrSr^^^^ - cln.UUn.ius. » pe.od. 
TheenaUommand,QUn Mrmb»«stt»««^^^ (ft,, 

bytes that are sent by the client: 

«eceiv.d: by --.uc.noao edu (4.1./SM1-4 l) 

id AA005O2; Mon, 19 Jul 93 12-.47.J2 Mo I 

Dace: Mon, 19 Jul 1993 12:47:31 -0700 
RGply-TO". r3tevens@noao.edu 
x-PVione: i-l 602 67G 167S 

X-wailcr: Mall User's Shell T/.^.-S 10/14/921 
To: rstevensSnoao. edu 
Subject: testing 



2, 3. 
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sima064 



0.0 

0.053197 (0.0532) 

0.300095 (0.2469) 
0.349297 (0.0492) 

0.659995 (0.3107) 
0.710105 (0.0501) 

0.990064 (0.2800) 
0.997129 (0.0071) 

1.259758 (0.2626) 
1.319947 (0.0602) 
1.359949 (0.0400) 
1.371820 (0.0119) 

1.859756 (0.4879) 
1.860323 (0.0006) 

2.040167 (0.1798) 
2.061677 (0.0215) 

2.249888 (0.1882) 



noao, 



PSH 1:78(77) ack 1 



220 noao.edu Sendmail 4.1/ 



— gSH 1:25(24) arlc7 A 



PSH 78:137(59) ack 25 



250 noao.edu Hello 



PSH 137:183(46) ack 64 

' 250 <i:stevena9iaun. tac.noao.edu>. . . \r\n 

.PSH 64:93(29) 133 



PSH 183:224(41) ack 93 
250 <ratBven6@noao. edu> . . . 

ack 99 
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PSH 224:274(50) ack 99 



354 Enter mail, end with 
ack 274 



\r\n 



_PSH99;492(39..^..i.... 
ioody oi mail inessage)"" 



dCk 492 
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PSH 492:495ri) .^L o>..f 

•\r\n 
PSH 274:293(19) ack 495 



250 Mail accepted\r\n 
^PSH 495:.'>0irfi^...u.n. 



9 
10 



13 



15 



PSH 293:323(30) ack 501 



221 noao.edu delivering maii\r\n 
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Figure 28.2 Basic SMTP mail delivery. 
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The first three lines, Received: and Message-Id:, are added by the MTA a.id the 
next nine are generated by the user agent. 
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SMTP Commands 

The minimal SMTP implementation supports eight commands. We saw five of them in 
the previous example: HELO, MAIL. RCPT, DATA, and QUIT. 

The RSET command aborts the current mail transaction and causes both ends to 
reset. Any stored information about sender, recipients, or mail data is discarded. 

The VRFY command lets the client ask the sender to verify a recipient address, 
without sending tnail. to the recipient. It's oiften used by a system administrator, by 
hand, for debugging mail delivery problems. Well show an example of this in the next 
section. 

The NOOP command does nothing besides force the server to respond with an OK 
reply code (200). 

There are additional, optional commands. EXPN expands a mailing list, and is 
often used by the system administrator, similar to VRFY. Indeed, most versions of 
Sendmail handle the two identically. 

Version 8 of Sendmail in 4.4BSD no longer handles the two identically. VRFY docs not expand 
aliases and doesn't follow . forward files. 

The TURN command lets the client and server switch roles, to send mail in the 
reverse direction, without having to take down the TCP connection and create a new 
one. (Sendmail does not support this command.) There are three other commands 
(SE^fD, SOML, and SAML), which are rarely implemented, that replace the MAIL com- 
mand. These three allow combinations of the mail being delivered directly to the user's 
terminal (if logged in), or sent to the recipient's mailbox. 

Envelopes, Headers, and Body 

Electronic mail Is composed of three pieces. 

- 1. The envelope is used by the MTAs for delivery. In our example the envelope was 
specified by the two SMTP commands: 

MAIL Prom: <ratevenseaun.tuc.noao.edu> 
RCPT to :<rstevenaQnoao.edu> 

RFC 821 specifies the contents and interpretation of the envelope, and the proto- 
col used to exchange mail across a TCP coimection. 

2. Headers are used by the user agents. We saw nine header fields in our example: 
Received, Me33age-Id, From, Date, Reply-To, X-Phone, X-Ma±ler, To, 
and Subject. Each header field contains a name, followed by a colon, fol- 
lowed by the field value. RFC 822 specifies the format and interpretation of the 
header fields. (Headers beginning with an X- are user-defined fields. The oth- 
ers are defined by RFC 822.) Long header fields, such as Received in the 
example, are folded onto multiple lines, with the additional lines starting with 
wliite space. 

3. The body is the content of the message from the sending user to the receiving 
user. RFC 822 specifies the body as lines of NVT ASCII text. When transferred 



